Conversation
|
|
||
| _Each function signature declares the types of its input parameters. If any type constraints are not met, implementations must indicate that an `invalid-type` error occurred. **If a function parameter accepts values constrained to a specific subset of a type and those constraints are not met, implementations must report that an `invalid-value` error occurred.**_ | ||
|
|
||
| _The [initial version of this JEP](./jep-014-string-functions.md) had a provision stating that_ “How and when those errors are raised is implementation specific”. _This provision has been removed. Implementation must perform type-checking for all function parameters_ before _attempting to evaluate the set of valid values for a given type._ |
There was a problem hiding this comment.
The requirement of type validation before range validation should not be limited to string functions... I think this deserves its own JEP rather than a replacement of JEP-14 (in which case I don't think it will be necessary to touch JEP-14 at all, because "How and when those errors are raised is implementation specific" can be interpreted within the context of that constraint (e.g., "how" might be "by exception" vs. "in a separate return value" and "when" might be "when parsing" [where possible] vs. "when evaluating").
|
I opened two related PRs: I know understand I opened them in the wrong project. It seems principles for error handling should be covered in their own section rather than within the context of functions. Should I open these PRs under https://github.com/jmespath-community/jmespath.spec? Or should I start a separate discussion or JEP? |
Yes please open them in the spec repository here, and, by the way, thank you for your feedback. I think we can start having discussions around existing features as issues, whereas brainstorming new ideas is better served by discussions. |
3 participants
See jmespath.test/#28.
This PR brings the following changes:
_Each function signature declares the types of its input parameters. If any type constraints are not met, implementations must indicate that an `invalid-type` error occurred. **If a function parameter accepts values constrained to a specific subset of a type and those constraints are not met, implementations must report - that an `invalid-value` error occurred.**_ + that an `invalid-value` error occurred. How and when those errors are raised is implementation specific.**_ + _The [initial version of this JEP](./jep-014-string-functions.md) had a provision stating that_ “How and when those + errors are raised is implementation specific”. _This provision has been removed. Implementation must perform + type-checking for all function parameters_ before _attempting to evaluate the set of valid values for a given type._